Fixup db.models.fields.Field overloads for pyright 1.1.378
#265
Conversation
minmax
force-pushed
the
fixes-for-pyright-1.1.378
branch
from
64371fe to
15ef8d9
Compare
|
Hi @sbdchd, should I remove |
| name: str | None = ..., | ||
| primary_key: bool = ..., | ||
| max_length: int | None = ..., | ||
| unique: bool = ..., | ||
| blank: bool = ..., | ||
| null: Literal[False] = ..., | ||
| null: Literal[False] = False, |
There was a problem hiding this comment.
I think we still want these to be ..., I think in general type stubs don't specify the actual default value
There was a problem hiding this comment.
if i understood it correctly, then we can't do ... more. We definitely need a default value, for the correct choice of @overload. microsoft/pyright#8860 was closed as "as designed", so i think stubs should accept this.
There was a problem hiding this comment.
Fixed a bug that results in a false negative when overloads overlap due to default values.
There was a problem hiding this comment.
I think we still want these to be
..., I think in general type stubs don't specify the actual default value
@sbdchd
How strong is your commitment to ...? Did the new rules in pyright introduce a bit of doubt?
The dev version of pylance already includes the new pyright, in a month it will appear for all users.
After which nullable fields will "break" in their projects, let's fix them in advance.
There was a problem hiding this comment.
ah seems like things have changed to allowing default values in stubs:
python/typeshed#8988 (comment)
keeping them in should be all good!
Fix for #264